-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: avoid many Symbol
to String
conversions.
#91948
Conversation
In local measurements I see the following rustdoc improvements on rustc-perf:
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit ac09b579d88c408116eb91a197850a86e6fb7aed with merge c35f8646bbfb5c225d701c6fd49948b853c27202... |
I guess we had the same idea at the same time: #91876 :P I'll close that one since the tests are failing and this covers it. |
☀️ Try build successful - checks-actions |
Queued c35f8646bbfb5c225d701c6fd49948b853c27202 with parent 2f4da62, future comparison URL. |
Finished benchmarking commit (c35f8646bbfb5c225d701c6fd49948b853c27202): comparison url. Summary: This change led to large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
Instruction counts and cycles show clear wins, smaller than I got locally, probably because I was profiling without jemalloc enabled. Wall times show no improvement in the default view, but if you show "insignificant" changes you can see up to 7%; I guess the wall times are so noisy in general that any non-huge change is considered insignificant. |
I have pushed an update that addresses most of the comments. |
This is super cool, thanks! Let's wait for @camelid's confirmation as well. |
I'll review this soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, this looks good, but I have some code quality concerns.
970b911
to
4848d5a
Compare
I just realized that I forgot to delete an outdated comment from an earlier commit (the one about @bors r=GuillaumeGomez rollup=never |
📌 Commit 4848d5a059a242e9d691f94b070863d76a520a24 has been approved by |
☔ The latest upstream changes (presumably #92844) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors p=1 (this is really conflict-prone) |
Particularly when constructing file paths and fully qualified paths. This avoids a lot of allocations, speeding things up on almost all examples.
I seem to recall that in general, it's best to request an allocation with a size that's a power of 2. The low estimate of 5 was probably a little too low as well.
4848d5a
to
c7147e4
Compare
@bors r=GuillaumeGomez rollup=never |
📌 Commit c7147e4 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b0ec3e0): comparison url. Summary: This change led to very large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Particularly when constructing file paths and fully qualified paths.
This avoids a lot of allocations, speeding things up on almost all
examples.
r? @GuillaumeGomez